CAMEL-24070: camel-spring-rabbitmq - Fix thread-unsafe lazy template creation in SpringRabbitMQProducer - #24727
Merged
Merged
Conversation
…creation in SpringRabbitMQProducer Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
gnodet
approved these changes
Jul 15, 2026
gnodet
left a comment
gnodet
left a comment
Contributor
There was a problem hiding this comment.
Clean thread-safety fix — the race in lazy template creation is real and the ReentrantLock approach is correct.
What works well:
- Lock pattern matches the existing
EndpointMessageListener.getTemplate()in this same component — consistent. inOutTemplate.start()moved inside the null-check is an important secondary fix: previously everygetInOutTemplate()call re-started the template, which is wasteful and potentially confusing.doStop()also guarded by the lock — prevents a race between a lateprocess()call and shutdown.Boolean.FALSE == sent→!sentis a good cleanup (identity comparison on autoboxed primitive).- The test design with a
CountDownLatchbarrier maximises contention to expose the race.
Checklist:
- Tests included (8-thread concurrent access test)
- No public API changes
- Thread-safety — lock scope is correct (covers check-then-act on both getters + stop)
- No
@authortags - CI — builds pending
Reviewed with Claude Code on behalf of gnodet. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.
Contributor
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
Contributor
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 9 tested, 29 compile-only — current: 9 all testedMaveniverse Scalpel detected 38 affected modules (current approach: 9).
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Claude Code on behalf of davsclaus
SpringRabbitMQProducerlazily creates itsRabbitTemplateandAsyncRabbitTemplatewithout synchronization. Since a producer is a singleton invoked concurrently by route threads, concurrent first messages can each create their own template; all but the last assignment are dropped without being stopped. In the InOut case each racing thread also starts its template, so the losers are leaked in started state.Changes
ReentrantLockto guardgetInOnlyTemplate(),getInOutTemplate(), anddoStop()— same pattern already used byEndpointMessageListener.getTemplate()in this componentinOutTemplate.start()inside the null-check so it is only called once on creation, not on every invocationBoolean.FALSE == sentidentity comparison on a primitive boolean to!sentSpringRabbitMQProducerThreadSafetyTestthat verifies concurrentgetInOnlyTemplate()calls from 8 threads always return the same instanceFixes: CAMEL-24070
Test plan
SpringRabbitMQProducerThreadSafetyTestpasses — 8 threads behind a barrier all get the same template instance